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GRAPHICS  TRANSLATORS  FOR  COMPUTER-AIDED  DRAFTING 
AND  DESIGN:  INTERFACE  ALTERNATIVES  FOR  THE 
A/E  COMMUNITY 


1  INTRODUCTION 


S 

' 
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Background 

The  Corps  of  Engineers  is  among  many  architectural/engineering  (A/E) 
agencies  making  greater  use  of  computer-aided  drafting  and  design  (CADD).  The 
CADD  industry  has  grown  significantly  in  the  past  2  years,  with  further  growth 
expected  in  the  areas  of  design  and  analysis.  However,  this  surge  in  the  in¬ 
dustry  has  come  without  standardization  among  manufacturers.  Moreover,  in 
efforts  to  gain  a  competitive  edge,  CADD  manufacturers  have  developed  new 
software  offering  unique  capabilities,  but  the  data  structures  are  protected 
as  trade  secrets  and  are  therefore  unavailable  to  clients  and  other  vendors. 

This  unbridled  development  and  competition  has  given  the  A/E  community 
many  quality  drafting  systems,  but  it  has  effectively  prevented  the  systems 
from  communicating  with  each  other.  Thus,  the  Corps  is  unable  to  take  advan¬ 
tage  of  the  graphics  information  becoming  increasingly  available  as  A/E  pro¬ 
fessionals  make  wider  use  of  CADD  tools. 

Related  to  the  lack  of  communication  between  CADD  systems  is  the  Corps' 
need  to  alter  and  archive  design  and  drafting  graphics  through  electronic 
means.  Maintaining  project  information  in  paper  form  throughout  the  design 
and  life  cycle  has  been  very  expensive  due  to  storage  requirements,  revision 
inconsistencies,  and  unnecessary  drafting. 

Most  problems  associated  with  electronic  media  communication  and  storage 
of  graphics  could  be  reduced  or  eliminated  by  an  acceptable  method  for  infor¬ 
mation  transfer  among  CADD  systems.  One  promising  method  uses  graphics  trans¬ 
lators  for  this  transfer.  Several  types  of  graphics  translators  are 
available,  each  with  advantages  and  drawbacks.  These  methods  should  be 
evaluated  for  possible  use  with  the  Corps  of  Engineers  Computer-Aided 
Engineering  and  Architectural  Design  System  (CAEADS)1  and  any  future  CADD 
equipment.  CAEADS  is  an  integrated  system  of  computer  aids  to  the  design 
process  for  military  construction,  supporting  the  design  and  review  activities 
of  Corps  District  offices  and  the  review  of  private  A/E  firms  under  contract 
with  the  Corps. 


^Daniel,  Mann,  Johnson,  and  Mendenhall,  Computer-Aided  Engineering  and  Archi¬ 
tectural  Design  System,  Vol  1,  Technical  Report  P-97/ADA067719  (U.S.  Army 
Construction  Engineering  Research  Laboratory,  January  1979). 
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Objective 


The  objective  of  this  study  was  to  evaLuate  alternative  graphics  trans¬ 
lators  for  transferring  architectural  data  (drawings,  geometry,  and  nongraph¬ 
ics)  between  different  CADD  systems. 


Approach 

The  state  of  the  art  in  graphics  translators  was  assessed  through  attend 
ance  at  numerous  conferences  on  that  topic.  Proposed  standards  for  these  pro 
grams  were  obtained  for  study  from  the  issuing  agencies.  Recent  results  from 
field  use  of  graphics  translators  were  considered. 


Scope 


This  evaluation  is  limited  to  the  Corps  of  Engineers'  projected  needs  in 
military  construction.  The  work  considers  all  phases  of  building  design  and 
documentation.  Other  Corps  activities  such  as  heavy  civil  design  or  mapping 
functions  are  not  considered. 


Mode  of  Technology  Transfer 

It  is  recommended  that  the  results  of  this  study  be  used  to  develop  an 
Initial  Graphics  Exchange  Specification  translator  for  CAEADS  to  evaluate 
potential  as  a  "front  end"  for  commercial  drafting  systems  and  as  a  "review 
tool"  for  design  layouts  prepared  on  other  CADD  systems. 
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2  CRAPHICS  TRANSLATOR  ROLE  IN  COMMUNICATION 


Military  design  often  involves  several  architectural  contractors  and  sub¬ 
contractors,  each  of  whom  may  use  a  different  CADD  system.  In  principle,  a 
graphics  translator  could  tie  together  the  many  systems  used  by  the  Corps  and 
contractors  by  providing  the  ability  to  communicate  between  different  systems. 

How  Could  the  Corps  Use  a  Graphics  Translator? 

A  graphics  translator  can  allow  districts  to  transfer  graphic  libraries 
and  nongraphic  information  (e.g.,  building  criteria)  in  an  electronic  format 
to  Districts  or  A/E  firms  rather  than  with  the  current  paper  documents.  This 
information  can  then  be  culled  quickly  to  provide  the  A/E  firm  with 
information  applicable  only  to  the  building  in  question,  eliminating 
extraneous  data  that  may  confuse  and  slow  the  designer.  Such  information 
given  at  the  project's  beginning  could  aid  in  providing  a  complete,  consistent 
design. 

Another  way  a  translator  could  benefit  the  Corps  is  as  an  interface  to 
CAEADS  review  modules.  The  Corps  will  most  likely  continue  to  have  at  least 
80  percent  of  its  military  workload  done  by  outside  A/E  firms.  Many  of  these 
firms  have  CADD  systems  and  recent  technology  in  optical  scanners  promises  to 
bring  non-CADD  users  on-line.  The  most  efficient  way  to  review  A/E  contractor 
projects  may  be  automatically  through  the  CAEADS  review  modules.  With  this 
system,  many  mundane  activities  necessary  to  insure  that  designs  comply  with 
applicable  criteria  can  be  done  accurately  and  quickly  without  human 
intervention.  This  leaves  the  reviewer  more  time  to  evaluate  the  concept  and 
quality  of  the  design  without  the  burden  of  minor  details  that  are  often 
easily  missed. 

Finally,  after  the  project  is  designed,  it  can  be  archived  or  passed  to 
the  facility  engineer  (who  may  have  yet  a  different  system)  for  facility  main¬ 
tenance.  The  district  can  also  archive  a  copy  of  the  project  for  future  ref¬ 
erence.  However,  if  the  building  later  requires  remodeling  or  additions, 
there  is  a  danger  that  the  current  CADD  equipment  will  not  be  compatible — an 
important  consideration  in  light  of  the  rapid  rate  of  change  in  systems. 

What  Information  Will  Be  Translated? 

The  scope  of  information  to  be  translated  will  grow  as  the  Corps  learns 
to  use  CADD  more  effectively  and  as  the  technology  for  systems  and  translators 
matures . 

The  first  kinds  of  information  to  be  translated  will  reflect  the  lowest 
common  denominator  in  the  industry.  For  example,  basic  drafting  documentation 
that  mimics  the  manual  contract  preparation  process  will  be  translated.  The 
information  will  include  basic  geometric  entities,  their  related  parameters 
such  as  line  type  and  line  weight,  and  probably  their  drawing  level.  Associ¬ 
ated  annotation  and  dimensioning  will  be  included  as  well  as  general  notes. 
Potential  problems  will  be  with  standardization  of  drafting  levels  and  font 


types  and  with  the  ability  to  retain  the  association  of  entities  int''  groups 
often  called  "cells"  or  subfigures. 


As  the  Corps  builds  libraries  of  drafting  information,  the  A/E  will  be 
provided  basic,  standard  drafting  data  such  as  sheet  layouts,  symbols,  and 
possibly  details  as  they  become  available.  As  drafting  systems  become  more 
intelligent,  additional  nongraphic  information  may  also  be  translated.  This 
may  include  the  ability  to  associate  graphic  entities  into  related  groups 
(cells)  and  to  provide  some  definition  of  what  the  related  groups  mean.  Two 
examples  are  (1)  associating  furniture  groups  into  a  workstation  definition 
with  catalog  numbers  and  (2)  defining  the  office  or  organization.  Another  po¬ 
tential  use  for  this  ability  is  to  automatically  reference  detail  numbers  both 
from  the  plan  to  the  detail  and  back  to  every  instance  of  the  detail  cut. 

Design  systems  eventually  will  provide  much  better  integration  of  graphic 
and  nongraphic  information,  effectively  replacing  many  drafting  system  func¬ 
tions.  Functional  requirements  (e.g.,  area,  relations,  fire-code,  and  handi¬ 
cap  criteria)  will  be  tied  directly  to  the  graphics  for  automated  analysis  of 
a  building  design.  To  do  this,  a  building  "model"  must  be  translated;  anno¬ 
tated  drawings  will  no  longer  be  acceptable  without  the  model.  As  a  result, 
the  translated  information  will  have  meaning  to  the  computer,  not  just  the  op¬ 
erator. 


What  Else  Is  Needed? 


Although  the  current  experience  with  translators  is  somewhat  limited,  it 
is  known  that  a  translator  alone  cannot  prepare  contract  documents  consis¬ 
tently.  The  translator  provides  only  the  ability  to  communicate  between  sys¬ 
tems.  It  neither  supplies  a  specific  building  data  format  nor  dictates  the 
content  of  what  is  provided.  To  standardize  the  contract  documents,  an  office 
procedure  should  be  developed  to  provide  consistent  format  and  content  between 
projects  and  between  districts.  This  could  reduce  the  common  complaint  by  A/E 
firms  that  no  two  districts  require  the  same  information  in  the  same  format. 

Districts  also  will  be  able  to  transfer  additional  information,  such  as 
standard  symbols  and  details,  in  a  form  that  would  provide  A/E  firms  with 
useful  drafting  aids.  Such  libraries  would  require  a  major  effort  to  develop 
and  maintain,  but  they  could  have  tremendous  impact  on  the  speed  of  contract 
development  and,  if  properly  used,  could  reduce  errors  in  the  documents  as 
we  1 1 . 
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J)  ALTERNATIVE  TRANSLATOR  FORMATS 


Direct  Translators 


A  direct  translator  is  a  program  that  wiLl  convert  a  project's  database 
from  one  computer  directly  to  another.  It  is  the  most  efficient  way  to  pass 
information  between  machines  since  the  software  developer  has  the  advantage  of 
knowing  which  machines  will  be  interfaced  and,  more  importantly,  the  specific 
capabilities  and  Limitations  of  each  system  (Figure  L). 

With  these  advantages,  why  not  use  direct  translators  for  passing  infor¬ 
mation  between  Corps  systems?  The  reason  for  not  doing  so  is  based  on  eco¬ 
nomics  and  practicality  rather  than  technical  aspects.  When  only  two  systems 
are  involved,  the  direct  translator  certainLy  is  the  most  efficient  way  to 
pass  data.  Only  two  translators  are  required — one  for  each  direction. 

When  direct  translators  must  be  written  for  several  systems,  the  number 
required  grows  exponentially.  For  example,  when  three  systems  are  involved, 
six  translators  are  needed;  four  systems  require  twelve  translators  to  be 
written  and  maintained. 

The  problem  can  become  further  complicated  as  muLtiple  versions  of  the 
systems  are  developed.  When  the  hardware  remains  the  same,  the  systems  usual¬ 
ly  are  upwardly  compatible.  But  when  new  hardware  is  introduced,  as  is  cur¬ 
rently  happening  in  the  industry,  vendors  often  must  support  multiple  versions 
of  the  programs  and  their  translators. 


Figure  1.  Direct  translator  concept 


At  Last  count,  more  than  16  systems  with  greater  than  1  percent  market 
share  had  been  designed  specifically  for  the  A/E  community.  MultipLe  versions 
of  these  systems  pLus  those  developed  for  other  industries  have  made  it 
impractical  for  vendors  to  maintain  direct  translators  for  their  customers. 
Therefore,  most  direct  translators  in  use  today  are  maintained  by  users  or 
third  party  software  houses  for  individual  customers  who  have  received  access 
to  each  system's  internaL  data  structure.  Although  direct  translators  can 
become  very  expensive,  there  are  times  when  they  may  be  a  better  alternative 
because  the  data  can  be  translated  more  efficiently.  For  the  most  part,  how¬ 
ever,  neither  vendors  nor  the  Government  can  afford  to  maintain  a  direct 
translator  for  every  possible  combination  of  equipment. 

The  Corps  experience  with  Direct  Translators  seems  to  bear  this  out. 
HuntsviLLe  Division  has  maintained  both  neutral  translators  such  as  SIF  and  a 
direct  translator  over  the  last  few  years.  The  direct  translator  was 
developed  under  contract  to  a  New  Jersey  firm  to  tie  on  Applicon  and 
Intergraph  together.  The  originaL  contract  to  develop  a  one-way  interface  was 
expected  to  take  approximately  6  months  to  develop.  However,  during  the 
contract  period,  one  of  the  CAD  vendors  upgraded  their  system,  effectively 
making  obsolete  much  of  the  previous  work.  As  a  result,  the  contract  was 
extended  to  a  year  with  the  cost  rising  accordingly.  Once  developed,  the 
translator  was  not  maintained  due  to  the  cost  and  quickly  became  obsolete. 
Huntsville  found  that  it  was  just  impractical  to  maintain  a  direct  translator 
as  a  custom  implementation  and  has  resorted  to  using  a  more  economical  SIF 
translator  that  is  maintained  by  the  CAD  vendor. 


Neutral  Translators 


An  alternative  type  of  translator  would  use  a  neutral  or  intermediate 
file  format.  This  concept  would  allow  individual  vendors  to  support  only  two 
translators:  one  for  passing  information  from  the  system  to  the  neutral 

format,  and  one  for  passing  information  from  the  neutral  format  to  another 
system  (Figure  2). 
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For  a  neutral  format  to  be  successful,  it  must  (1)  anticipate  every  data 
element  that  might  be  used  or  be  flexible  enough  to  accommodate  future  exten¬ 
sions  that  might  be  required,  and  (2)  be  a  generally  accepted  standard  by  ven¬ 
dors  and  users.  To  be  complete,  the  format  would  need  to  have  an  equivalent 
entity  for  each  proprietary  data  element  that  might  be  developed.  That  is, 
unless  all  data  elements  could  be  converted  to  a  neutral  format,  data  would  be 
lost . 


Since  it  is  unreasonable  for  any  standard  to  anticipate  future  system 
capabilities,  the  format  must  be  flexible  to  allow  for  unforeseen  enhance¬ 
ments.  That  is,  the  format  must  allow  changes  in  the  system  without  negating 
earlier  defined  entities.  Although  this  task  is  complex,  it  can  be  done  with 
careful  definition  and  involvement  by  as  many  vendors  and  users  as  possible. 
Such  effort  would  result  in  a  concensus  standard. 

In  contrast,  a  format  may  be  technically  competent  and  yet  not  provide  a 
practical  solution  to  the  problem.  A  true  test  of  the  format's  acceptance  is 
the  number  of  vendors  who  are  willing  to  write  translators  in  that  format.  It 
seems  many  vendors  have  little  desire  to  write  translators  at  all.  Many  feel 
they  lose  a  marketing  advantage,  particularly  with  large  companies,  when  other 
systems  can  be  made  compatible  with  the  companies'  existing  ones.  This  tends 
to  force  the  company  to  buy  all  its  systems  from  a  single  vendor  to  maintain 
compatibility.  Only  recently  have  system  owners  begun  to  demand  translators 
to  allow  communication  with  other  machines. 

Standard  Interchange  Format  (SIF) 

The  first  neutral  format  to  receive  general  acceptance  by  the  A/E  commun¬ 
ity  was  the  SIF,  developed  by  the  Intergraph  Corporation  in  1979.  Before 
that,  the  CAMRAS,  Siggraph's  CORE,  and  CALCOMP  neutral  formats  existed  but 
were  not  recognized  by  the  industry  as  general  interface  media.  After  devel¬ 
oping  several  direct  translators  for  its  clients,  Intergraph  recognized  the 
need  for  a  neutral  format — both  as  a  general  standard  and  to  reduce  the  time 
needed  to  develop  special-purpose  translators  for  its  clients. 

At  the  time  of  SIF's  development,  Intergraph  was  primarily  supporting 
drafting  activities  for  mapping,  petrophysical  exploration,  and  facilities 
management.  Since  then,  general  cartographers,  utilities,  and  land  use  mana¬ 
gers  have  used  the  SIF  format.  Most  major  CADD  systems  now  offer  SIF  trans¬ 
lators. 

The  SIF  is  divided  into  four  major  categories  of  data  definition:  char¬ 
acteristic,  geometric,  textual,  and  miscellaneous.  The  characteristics  cate¬ 
gory  provides  geometry  and  text  with  basic  parameters  such  as  line  width, 
color,  line  type,  and  text  with  height,  width,  size,  and  rotation.  This  is 
defined  before  any  lines  and  text  are  sent  and  remains  in  effect  until  new 
commands  are  sent  to  alter  the  parameters. 


3P.  Brown,  "ISIF:  An  Alternate  Standard  Interchange  Format  for  Graphic  and 
Nongraphic  Information,"  Presentation  to  the  CAD/CAM  Standards  Conference  on 
ICES  and  Alternatives  (May  1983). 

^P.  Brown. 
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The  geometry  category  defines  the  specific  types  of  geometry  to  be 
drawn.  In  the  current  version  of  SIF,  the  geometry  represented  can  be  either 
two-  or  three  dimensional  (not  solids  or  surface  modeling)  with  similar  com¬ 
mands  supporting  each  type. 

SIF  currently  supports  two  types  of  textual  data:  (1)  the  single  line  of 
text  and  (2)  multiple  lines  of  text  treated  as  a  block  of  data.  The  miscella¬ 
neous  category  supports  definitions  of  associated  (nongraphic)  information. 

SIF  files  are  designed  with  user  edit  capability.  To  support  this  func¬ 
tion,  Intergraph  made  the  format  free,  without  major  ties  from  one  line  of 
text  to  the  next.  However,  this  capability  has  a  price.  First,  the  non¬ 
graphic  information  that  can  be  associated  with  the  graphics  has  limita¬ 
tions.  Also,  there  is  no  ability  to  provide  backpointers  in  the  data.  In  the 
hierarchical  database  management  system  (DBMS)  that  Intergraph  currently  mar¬ 
kets,  this  is  not  a  problem.  However,  in  the  network  DBMS  soon  to  be  offered, 
the  backpointers  would  be  lost.  The  SIF  is  claimed  to  be  extendible,  although 
major  revisions  will  be  required  to  support  a  network  DBMS  capability.  In  ad¬ 
dition,  the  editing  ability  will  be  lost,  but  this  is  not  really  an  essential 
feature.  Currently,  the  backpointers  may  be  of  little  use  in  some  drafting 
systems,  this  will  soon  be  a  very  important  feature  in  design  systems  and  ad¬ 
vanced  drafting  systems  as  well.  Table  1  gives  a  detailed  list  of  SIF  enti¬ 
ties. 

Initial  Graphics  Exchange  Specification  (IGES) 

While  Intergraph  was  developing  SIF  for  its  users,  the  U.S.  Air  Force 
(USAF )  was  attempting  to  develop  a  computer-aided  design/computer-aided  manu¬ 
facturing  (CAD/CAM)  standard  for  the  manufacturing  industry.  The  ICES  was  a 
project  under  the  USAF  Integrated  Computer-Aided  Manufacturing  (ICAM)  pro¬ 
gram.  Funded  by  the  USAF,  Army,  Navy,  and  NASA,  the  IGES  committee  was  formed 
to  provide  an  acceptable  standard  for  communicating  drawing  and  geometry  data 
between  CAD/CAM  systems.  As  the  result  of  a  Department  of  Defense  Manufac¬ 
turing  Technology  Advisory  Group  meeting  in  September  1979,  the  IGES  committee 
was  charged  with  developing  a  format  to  meet  the  needs  of  Government  and  in¬ 
dustry  by  early  1980. 

A  USAF  ICAM  contract  was  let  to  the  National  Bureau  of  Standards  to 
direct  and  coordinate  the  IGES  effort.  In  addition  to  the  1980  target  date, 
the  contract  required  that  two  committees  be  formed  to  support  ICES'  implemen¬ 
tation.  These  committees  were  to  be  (1)  a  working  group  for  technical  guid¬ 
ance  as  the  IGES  project  became  a  standard,  and  (2)  a  steering  group  to  guide 
management  decisions.  By  summer  1980,  over  42  companies  had  participated  in 
the  IGES  effort  by  having  one  or  more  members  on  these  committees. 


^B.  M.  Smith  and  J.  Wellington,  IGES,  A  Key  Interface  Specification  for 
CAD/CAM  Systems  Integration  (National  Bureau  of  Standards,  November  1983). 
^B.  M.  Smith  and  J.  Wellington. 


Table  1 


Detailed  Format  Comparison 


CAEADS* 


General  Definitions 


Character  form 

ASCII  X 

BINARY 

Measurement  units  X 

General  leader  information 

System  ID,  software  version  X 

Translator  identification  X 

Project  identification  X 

Designer  X 

Organization  X 

Size  of  definition  space  X 

Mathematics  precision 
Minimum  resolution 


Geometric  Definitions 


Point  X 

Line  X 

Line  string  X 

Circular  arc 

Defined  by  center 

Defined  by  edge  X 

Conic  arc 

Complex  string  (composite  curve) 

Ellipse 

User  defined  shape  X 

Copious  data  (pairs,  triples,  sextuples) 

Planes  (bounded/unbounded)  X 

Transformation  matrix  X 

Tabulated  cylinder 
Surface  of  revolution 

Ruled  surface  X 

Parametric  spline  curve 
Parametric  spline  surface 


ICES 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


Graphic  Characteristics 

Line  weights 
Line  types,  patterns 
Line  color 
Area  patterns 


X 

X 

X 

X 


X 

X 

X 


SIF 
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xxx  X  XXXXXXXXX  X  X  X  X 


Table  1  (Cont'd) 


Area  color 
Dimensions 
Angular 
Linear 
Ordinate 
Point 
Radius 
Diameter 
Centerline 
Witness  line 
Flag  note 
General  note 
Leader 

Arrowhead  types 
Open 
Closed 
Slash 
Dot 

Rectangle 

Text 

Line 

Paragraph 

Character  set  definition 
Font  definition 
Mixed  case  options 
Text  justification 
Vertical  text 


CAEADS*  ICES  SIF 


X 


X 


X 

X 

X 

X 

X 

X 

X 

7 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


7 

7 

7 

7 

7 

7 

7 

7 

7 

X 

7 


X 

X 

X 

X 


X 

X 

X 

X 

X 


X 

7 

7 

7 

? 


X 

X 

X 

X 

X 

X 


X  X 

X 
X 
X 
X 
X 
X 


Logical  Relations 

Associativity  definition 
Associativity  instance 
Property 

Subfigure  definition 
Subfigure  instance 
View 

Drawing  identification 
Macro  definitions  (e.g.,  shape) 
Macro  instance 
Overlay 
Data  structure 
Hierarchical 
Network 
Relational 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


*CAEADS--Capabil it ies  required  to  interface  with  CAEADS;  IGES—capabilit 
currently  available;  SIF — capabilities  currently  available. 


XX  XX  XXXX  XXX 


The  IGES  Version  1.0  Specification  resulting  from  ICES  committee  work  was 
submitted  to  the  American  National  Standards  Institute  (ANSI)  for  approval  as 
an  ANSI  standard.  The  ANSI  subcommittee  Y14.26  on  Computer  Aided  Preparation 
of  Product  Definition  Data  voted  to  include  Version  1.0  as  Sections  2  through 
4  of  a  five-part  draft  standard  to  be  submitted  into  the  formal  review  proce¬ 
dure.  After  technical  review  for  consistency,  the  final  document  was  approved 
as  an  ANSI  standard  in  September  1981. ^ 

8 

Adoption  by  vendors  has  been  swift,  with  two  separate  surveys  showing  a 
clear  trend  toward  implementation.  The  first  survey  showed  that  10  vendors 
supported  IGES  translators,  whereas  the  second  survey  showed  20  companies 
offering  these  translators  with  an  additional  19  companies  currently  develop¬ 
ing  them.  The  latest  data^  indicate  that  15  different  translators  can  pass 
files  correctly  in  public  intersystem  testing  and  a  fairly  large  number  are 
now  marketed  (Table  2). 

IGES  Format.  As  with  SIF,  IGES*  file  structure  is  divided  into  several 
major  components:  start,  global,  directory  entry,  parameter,  and  terminate 
sections.  The  start  section  is  not  machine  readable;  its  purpose  is  to 
provide  a  prologue  to  the  file.  Any  number  of  cards  can  be  used  in  this 
section  to  provide  the  user  with  general  information  about  the  file. 

The  global  section  contains  information  about  the  source  system's  post¬ 
processor  so  that  the  receiving  system's  preprocessor  can  process  the  file 
properly.  Information  such  as  the  date  of  file  generation,  minimum  resolution 
used,  and  unit  of  measure  is  listed. 

The  directory  entry  section  consists  of  two  records  for  every  entity 
used.  These  records  contain  information  common  to  all  entity  types.  Informa¬ 
tion  such  as  the  type  and  version  of  that  entity,  the  level  on  which  it  is  to 
be  located,  and  line  weight  are  examples  of  information  in  these  records.  In 
the  IGES  format,  an  entity  can  be  one  of  two  major  types:  geometry  or  struc¬ 
ture.  Lines,  arcs,  and  other  more  sophisticated  graphic  elements  comprise  the 
geometry  type.  The  structure  type  handles  all  nongeometry  to  be  supported — 
associativity  definitions,  properties,  annotation  (e.g.,  notes,  dimensions) 
and  its  most  powerful  function,  the  ability  to  define  a  view  (see  Other  Capa- 
bilities). 


The  parameter  cards  support  definition  of  the  specific  entity.  For  ex¬ 
ample,  if  a  circular  arc  entity  was  being  defined,  information  about  the  loca¬ 
tion  of  the  center  might  be  required.  If  a  general  note  or  properties  of  the 
arc  were  to  be  added,  parameter  cards  support  this  type  of  definition.  For 
each  entity  required,  an  associated  parameter  card  also  will  be  needed  to  help 
define  the  entity. 

The  terminate  section  consists  of  one  card.  This  section  is  required  to 
define  the  end  of  the  project  file,  completing  the  IGES  deck. 


.  M.  Smith  and  J.  Wellington. 

°C.  Machover,  "Status  Report:  Vendor  Update,"  Presentation  to  the  CAD/CAM 
Standards  Conference  on  IGES  and  Alternatives  (May  1983). 

^B.  M.  Smith  and  J.  Wellington. 
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Availability  of  ICES  Translators 

This  list  includes  firms  that  have  general-purpose  drafting  systems  and 
specialized  A/E  packages. 
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Ph 

C/5  U 

OS 

Appl icon 

Y 

Y 

Y 

2 

2 

A.  M.  Bruning 

N 

2 

Autotrol 

Y 

Y 

Y 

5 

Bausch  &  Lomb 

Y 

Y 

Y 

2 

Cadam  Inc. 

N 

4 

Cadi ing 

N 

2 

Cal comp 

N 

3 

Calma 

Y 

Y 

Y 

12 

6 

Camax 

N 

4 

ComputerVision 

Y 

Y 

Y 

50-100 

4 

Control  Data 

Y 

Y 

Y 

40 

4 

Data  Technology 

N 

4 

Decision  Graphics 

N 

4 

Engineering  Systems 

Y 

4 

Gerber 

Y 

Y 

Y 

5 

4 

Graf tek 

Y 

Y 

Y 

4 

Holguin 

N 

4 

IBM 

Y 

Y 

Y 

Y 

5 

Information  Displays 

N 

4 

Interactive  Systems 

N 

4 

Intergraph 

Y 

Y 

Y 

25 

4 

K  &  E 

N 

2 

Marc  Software 

N 

4 

Matra  Datavision 

Y 

Y 

1 

2 

McAuto  Unigraphics 

Y 

Y 

Y 

6 

MCSI 

Y 

Y 

Y 

120 

4 

Prime 

Y 

Y 

Y 

Y 

6 

Project  Software 

N 

4 

Sutnmagraphics 

N 

4 

Systemhouse 

N 

4 

Tektronix 

N 

4 

T  &  W  Systems 

N 

4 

Source:  B.  M.  Smith  and 

J. 

Wei l ington. 

Reference  notes:  (1)  ICES  questionnaire  5/82,  (2)  telephone  contact,  (3) 
third-party  source,  (4)  Machover  survey  5/83,  (5)  press  release,  (6)  ICES  Com¬ 
mittee. 


Other  Capabilities.  IGES  supports  two  concepts  not  found  in  SIF  which 
are  very  important  in  developing  an  advanced  drafting  system  and  imperative  in 
computer-aided  design.  These  concepts  are  (1)  providing  backpointers  from  the 
associated  information  and  (2)  defining  views.  The  need  for  backpointers  in 
networking  database  systems  was  mentioned  earlier;  this  is  needed  primarily  to 
support  increased  intelligence  in  systems. 

With  the  views  concept,  IGES  allows  two  types  of  information  to  be  trans¬ 
lated  from  one  system  to  another:  the  drawing  that  may  or  may  not  represent 
the  actual  building  model  and  the  building  model.  IGES  permits  the  picture  on 
the  drawing  to  come  indirectly  from  an  actual  building  model  if  needed.  This 
gives  designers  the  flexibility  to  design  the  model  in  three  dimensions  and, 
in  effect,  take  pictures  or  cuts  through  the  building  using  the  view  com¬ 
mand.  Figure  3  shows  how  the  model,  which  is  defined  in  three  dimensions,  and 
its  two-dimensional  representation  are  separated.  This  concept  aLlows  both 
design  drawings  and  the  actual  building  model  to  be  translated  without  a  data 
loss.  Further,  changes  could  be  made  to  the  model  that  would  allow  the 
drawing  to  be  updated  automatically.  This  is  a  primary  difference  between 
current  drafting  systems  and  a  modeling  system  such  as  CAEADS.  Future  build¬ 
ing  design  systems  will  generate  the  model  as  well  as  the  drawings  for  Corps 
review.  Therefore  a  translator  format  is  needed  that  can  support  both  current 
drafting  systems  and  future  modeling  systems.  To  date,  IGES  is  the  only 
format  that  provides  that  capability. 

Other  Neutral  Formats 

One  neutral  translator  format  that  has  been  used  improperly  with  limited 
success  is  the  CALCOMP.  This  format  was  designed  specifically  to  provide  a 
machine-independent  format  for  Calcomp  Corporation's  family  of  graphics  plot¬ 
ters.  As  a  result,  it  cannot  support  the  transfer  of  nongraphic  information 
between  machines.  It  has  had  limited  success  in  passing  simple  files,  such  as 
design  details,  between  machines.  However,  even  this  is  not  easy  since  there 
is  no  way  to  determine  at  what  level  the  lines  are  to  be  placed.  Because  of 
these  major  limitations,  no  further  consideration  was  given  to  this  format  as 
a  standard  neutral  translator. 


PERSPECTIVE! 

VIEW 


Figure  3.  IGES  View  concept — two-dimensional  display  of  three- 
dimensional  model. 
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L\  DRTAILED  EVALUATION  OF  AN  ICES  TRANSLATOR 


Vendors'  Problems 

Several  vendors  have  written  translators  since  the  adoption  of  IGES  as  an 
ANSI  standard  in  September  1981.  These  systems  have  been  only  partially  suc¬ 
cessful,  partly  due  to  a  lack  of  definition  in  the  IGES  format  and  to  the  gen¬ 
eral  understanding  among  translator  developers. 

By  evaluating  an  implementation  of  this  standard,  it  is  possible  to 
understand  the  vendor's  problems.  The  Corps  is  testing  Intergraph  drafting 
systems  at  Huntsville  Division  (military)  and  St.  Louis  District  (civil  works) 
for  their  potential  in  the  Corps'  design  process.  These  systems  are 
representative  of  the  larger  systems  being  used  by  many  A/E  firms  country-wide 
and  were  used  in  this  evaluation. 

Intergraph's  approach  has  not  been  to  consider  a  translation  device  for 
any  other  vendor's  equipment.  Rather,  the  only  consideration  has  been  to  pro¬ 
vide  a  translation  from  IGES  to  the  Interactive  Craphics  Design  System  (IGDS) 
and  back  to  ICES.  With  this  loop  closed,  Intergraph  considers  that  the  trans¬ 
lation  requirements  to  IGES  Version  1.0  have  been  met  and  that  any  difficulty 
in  reading  files  produced  on  another  system  must  be  blamed  on  the  other 
system.  This  point  is  important.  All  of  IGES  Version  1.0  is  supported 
through  the  Intergraph  translator;  however,  this  does  not  mean  an  IGDS  file 
produced  using  generic  software  under  normal  operating  procedures  will  trans¬ 
fer  completely  into  an  IGES  file.  To  prove  the  translation  on  their  system, 
users  apply  a  reversal;  that  is,  a  file  is  translated  from  IGDS  to  IGES  and 
from  IGES  back  to  IGDS.  For  a  true  evaluation,  the  translator  should  be  used 
with  a  different  system  as  well. 

An  informal  task  group  of  approximately  40  users  with  ICES  concerns  met 
in  1983.  Roughly  one-third  of  the  group  had  installed  IGES  but  only  one  had 
translated  successfully  from  IGDS  to  IGES  and  back  to  IGDS.  Translations  be¬ 
tween  Intergraph  and  ComputerVi sion  systems  are  now  completed  routinely. 

The  IGES  translation  is  done  by  two  separate  processes,  IGI  and  ICO,  and 
is  supported  by  the  Intergraph  Standard  Interchange  Format  (ISIF).  IGES- 
mput,  or  IGI,  is  the  IGES  translator  that  changes  data  from  the  IGES  format 
to  an  ISIF  ASCII  file.  IGES-output,  or  ICO,  is  the  IGES  translator  that 
changes  data  from  an  ISIF  ASCII  file  to  the  IGES  format.  The  IGES  standard 
refers  to  these  translators  as  pre-  and  postprocessors;  thus,  IGI  is  a  post¬ 
processor  and  IGO  is  a  preprocessor. 

Figure  4  shows  how  Intergraph  supports  these  two  IGES  translators.  IGI 
translates  three-dimensional  graphics  data  in  IGES  format  to  an  ISIF  ASCII 
file.  IGO  translates  a  three-dimensional  ISIF  ASCII  file  into  an  IGES  format¬ 
ted  file.  Both  translators  use  the  ISIF  to  create  and  decode  the  actual  IGDS 
design  file.  In  effect,  IGI  reads  an  IGES  file  and  creates  an  ISIF  ASCII 
file,  whereas  IGO  reads  an  ISIF  ASCII  file  and  translates  it  into  an  IGES 
file. 


OUTPUT 


Figure  4.  Intergraph  ICES  translation  process. 


Elements  Supported  by  ICES 


In  its  initial  form,  the  Intergraph  implementation  of  ICES  supports  about 
40  entity  types.  In  IGES  terminology,  all  graphic  and  nongraphic  data  types 
are  called  "entities"  and  are  classified  as  one  of  the  following: 

1.  Geometry 

2.  Annotation 

3.  Structure 

These  correspond  roughly  to  the  following  Intergraph  IGDS  concepts: 

1.  IGDS  graphic  elements 

2.  IGDS  text  and  dimensioning  elements 

3.  IGDS  graphic  group,  cell  patterning,  font  definition,  property,  and 
attribute  information. 

IGES  does  not  lend  itself  to  a  one-to-one  mapping  with  IGDS.  Since  IGES 
is  an  incomplete  specification  and  does  not  support  some  files  held  within  the 
Intergraph  system,  Intergraph  chose  to  map  IGES  entities  into  IGDS,  and  back 
out  to  IGES  rather  than  attempting  to  map  all  IGDS  entities  into  IGES.  The 
geometric  entities  supported  are; 

1.  Circular  arc 

2.  Composite  curve 

3.  Conic  arc 

4.  Copious  data 

5.  Plane 

6.  Line 

7.  Parametric  spline  curve 

8.  Parametric  spline  surface 

9.  Point 

10.  Ruled  surface 

11.  Surface  of  revolution 

12.  Tabulated  cylinder 

13.  Transformation  matrix. 
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Nongeometric  entities  supported  are 

1.  Angular  dimension 

2.  Centerline 

3.  Diameter  dimension 

4.  Flag  Note 

5.  Ceneral  label 

6.  General  note 

7.  Leader  (arrow) 

8.  Linear  dimension 

9.  Ordinate  dimension 

10.  Point  dimension 

11.  Radius  dimension 

12.  Section 

13.  Witness  line. 

Structure  entities  supported  are: 

1.  Associativity  definition 

2.  Associativity  instance 

3.  Drawing 

4.  Line  font  definition 

5.  Macro  definition 

6.  Macro  instance 

7.  Property 

8.  Subfigure  definition 

9.  Subfigure  instance 


Further  explanations  and  definitions  of  these  entities  are  available  else¬ 
where.  10 

Associated  data  not  supported  include  the  entire  Data  Management  Retriev¬ 
al  System  (DMRS)  file.  This  Intergraph  file  can  link  nongraphic  attribute 
data  with  graphic  elements  and  is  designed  with  a  hierarchical  structure. 

The  ability  to  define  graphic  elements  as  cells  (groups  of  entities  that 
can  be  manipulated  as  single  units)  as  well  as  nested  cells  (cells  grouped  to¬ 
gether  to  form  complex  cells)  is  lost  after  translation  into  ICES.  Complex 
elements  are  also  lost  when  transferred  into  IGES.  For  example,  a  polygon 
drawn  using  the  "Place  Block"  or  "Place  Shape"  command  will  not  transfer. 

Place  Block  allows  the  user  to  define  a  rectangle  by  locating  diagonal  cor¬ 
ners.  To  modify  the  element,  any  corner  can  be  relocated.  Since  the  block 
was  originally  defined  by  a  diagonal,  the  diagonal  is  being  modified.  Place 
Shape  allows  the  user  to  define  any  irregular  polygon  by  locating  successive 
points  as  long  as  the  first  and  last  points  are  coincident.  To  modify  the 
polygon,  any  vertex  can  be  relocated  and  the  two  sides  pertinent  to  the  vertex 
will  be  adjusted  as  required.  These  elements  must  be  redefined  as  line 
strings  to  allow  transfer. 

For  a  thorough  definition  of  the  entities  supported  by  IGES  Version  1.0, 
a  review  of  ANSI  Y14. 26M-1981 ,  Sections  3  and  A,  is  highly  recommended.  IGES 
Version  2.0  was  published  in  February  1983  and  clarifies  some  of  Version  1.0; 
however,  the  ANSI  committee  has  not  yet  adopted  this  document,  and  Version  3.0 
to  address  solids  modeling  is  under  development. 


10 


American  National  Standards  Institute  (ANSI)  Standard  Y14.26M-1981,  "Engi¬ 
neering  Drawing  and  Related  Documentation  Practices — Digital  Representation 
for  Communication  of  Product  Definition  Data"  (1981). 


5  STATUS  REPORT  OF  EXISTING  ICES  TRANSLATOR 


As  part  of  a  contract  with  the  USAF  Product  Definition  Data  Interface 
(PDDI)  project,  3ooz,  ALlen  and  Hamilton  were  tasked  with  the  evaluation  and 
verification  of  the  ANSI  Y14.26M  version  of  the  original  ICES  proposed  stan¬ 
dards.  That  study  gives  an  independent  view  of  the  current  translators' 
success.  It  assessed  the  translators'  level  of  development  and  evaluated 
ICES'  ability  to  deal  with  product  definition  data.  The  work  was  done  within 
the  limits  of  current  CAD  technology,  including  two-dimensional  drafting, 
three-dimensional  wireframes  modeling,  and  three-dimensional  surface  model¬ 
ing.  Since  solids  modeling  is  not  supported  in  the  ANSI  standard,  it  was  not 
considered  (it  will  be  available  in  ICES  Version  3.0). 

In  a  3-month  study  of  12  sites  represent’ng  12  different  vendors,  sepa¬ 
rate  tests  were  done  to  evaluate  both  preprocessors  and  postprocessors.  The 
test  examples  were  from  aerospace  syste"'  manufacturers  but  are  acceptable  for 
assessing  basic  capabilities.  They  are  not,  however,  suitable  for  testing  the 
database  sizes  expected  for  architectural/engineering/construction  (A/E/C) 
projects.  It  is  generally  agreed  that  ICES  expands  the  native  databases  5  to 
6  times.  In  some  Corps  projects,  integrated  ICES  files  could  grow  as  large  as 
60  MB  (native),  or  360  MB  in  ICES  format. 

The  study  found  that,  in  general,  ICES  can  suitably  transfer  mechanical 
parts  models  between  CADD  systems  and  that  support  for  ICES  within  the  CADD 
vendor/user  community  is  widespread.  However,  the  study  showed  that  several 
problems  with  ICES  are  slowing  its  progress. 

Moreover,  as  in  virtually  any  attempt  to  interface  dissimilar  systems 
with  a  specified  format,  the  ICES  approach  is  not  "neutral."  This  is  because 
"ICES  is  based  on  first  generation  commercial  CAD  system  representation  of 
geometry  and  annotation"  and,  "as  such,  (newer)  systems  that  differ  from  this 
representation  have  difficulty  in  processing  some  IGES  entities."  The  indus¬ 
try's  continued  development  will  probably  see  more  and  more  vendors  using  dif¬ 
ferent  representatives — a  trend  that  will  escalate  this  problem. 

Indeed,  in  the  case  of  CAEADS,  it  would  be  rather  straightforward  to 
write  an  IGES  out  translator  that  would  be  usable  by  most  drafting  systems. 
However,  the  reverse  is  not  true.  Topology  and  other  related  data  missing 
from  a  "dumb"  system  are  very  hard  to  create.  In  general,  you  can  only  lose 
information  in  a  translation,  not  gain  it.  Very  few  drafting  systems  store 
this  kind  of  information. 

Another  problem  shown  by  the  study  is  that  IGES  is  often  too  flexible, 
causing  confusion  when  developing  translators.  That  is,  several  entity  combi¬ 
nations  may  be  available  to  describe  a  given  part  or  feature.  The  manufac¬ 
turer's  choice  is  based  on: 

1.  Entities  available  on  the  CADD  system 

2.  Ease  of  implementation 


^Booz,  Allen,  and  Hamilton,  Inc.,  "Report  to  the  NBS  ICES  Test,  Evaluation 
and  Support  Committee"  (October  1983). 


3.  Compactness  of  representation 


4.  Required  accuracy/functionality 

5.  Other  interface  requirements. 

CADD  systems  also  may  have  "entities  not  explicitly  defined  in  ICES  that 
can  be  approximated  by  existing  ICES  entities  or  created  with  the  user-defined 
ICES  entity  structures."  In  addition,  emphasis  can  be  on  (1)  the  preproces¬ 
sor,  by  defining  the  information  output  in  IGES  format  as  explicitly  as  pos¬ 
sible  so  that  little  postprocessor  interpretation  is  needed,  or  (2)  the  post¬ 
processor,  by  requiring  it  to  interpret  the  entities  it  processes.  Thus,  al¬ 
though  some  flexibility  is  required  for  mapping  entities  between  dissimilar 
systems,  IGES  is  too  flexibLe  and  can  lose  information  during  translation.  It 
was  found  that  the  ICES  demands  substantial  postprocessor  interpretation  and 
that  inconsistent  interpretation  can  result. 

This  study  recommends  that  entity  mapping  choices  be  controlled  to  pre¬ 
serve  model  accuracy  and  functionality.  It  further  states  that  changes  to  the 
standard  and  additional  recommended  practices  are  required.  "Recommended 
practices"  are  informal  documents  that  suggest  methods  of  using  translation 
capabilities.  In  effect,  they  are  a  quick  answer  to  vague  requirements  in  the 
standard.  Although  they  may  soLve  the  problem  indirectly,  they  should  be  con¬ 
sidered  for  incorporation  into  the  next  version  of  the  standard. 

The  study  identified  one  other  major  problem  of  high  importance  in  A/E/C 
implementations.  In  particular,  wide  variations  were  found  in  the  processing 
time  required  to  read  and  write  IGES  files.  Processing  times  were  not  quanti¬ 
fied,  as  they  were  a  function  of  many  parameters  not  controlled  in  the  study 
(e.g.,  CPU  size  and  memory  capacity  and  whether  the  system  is  dedicated  or 
shared  by  several  users).  However,  these  researchers'  estimates  of  processing 
time  per  entity  ranged  from  0.01  to  1.0  sec  for  postprocessing.  Preprocessing 
usually  is  done  as  much  as  four  times  faster  than  postprocessing  because  of 
the  known  environment  and  the  minimal  error  checking  required.  The  test 
method  did  not  consider  estimated  IGES  file  sizes  that  might  be  found  in  a 
manufacturing  environment. 

The  study  has  reinforced  some  of  the  A/E/C  subcommittee's  concerns. 

First,  much  further  definition  of  the  building/site  model  is  required  to  pro¬ 
vide  efficient  translation  of  files.  Also,  a  way  must  be  found  to  create  com¬ 
pact  IGES  files.  The  NBS  A/E/C  subcommittee  is  currently  working  in  those  two 
areas  with  cooperation  of  the  plant/process  piping  subcommittee. 

Three  new  IGES  capabilities  have  been  discussed  in  committee  to  resolve 
tiie  volume  of  information  in  the  A/E/C  environment.  First,  the  ability  to 
segment  a  file  by  any  reasonable  means  (e.g.,  by  disciplines  or  building  lev¬ 
el)  would  allow  project  subsets  from  several  individual  design  consultants  to 
be  transmitted  to  a  lead  designer  for  coordination.  This  way,  updates  could 
be  made  without  retransmitting  the  entire  database. 

Although  technically  feasible,  the  mechanics  involved  with  such  a  system 
are  quite  complicated.  A  more  modest  proposal  (technically)  is  to  incorporate 
a  library  concept  allowing  only  project  unique  data  to  be  transmitted.  This 
would  require  sending  and  receiving  systems  to  have  the  same  library. 


These  techniques  promise  to  reduce  the  size  of  files  to  be  transmitted. 
However,  as  long  as  a  common  "neutral"  format  is  maintained,  the  IGES  files 
will  remain  much  longer  than  the  native  files  that  were  used.  Future  technol 
ogy  may  resolve  part  of  this  problem  by  reducing  processing  and  storage  costs 
and  by  increasing  processor  speeds. 


6  CONCLUSIONS  AND  RECOMMENDATIONS 


Alternative  graphics  translators  have  been  studied  for  potential  in 
transferring  architectural  data  between  different  CADD  systems.  This  study 
focused  on  two  types  of  translators — direct  and  neutral. 

Direct  translators  are  not  a  practical  solution  to  Corps  needs  because 
the  number  of  these  programs  required  increases  exponentially  with  the  number 
of  systems  involved.  Neutral  translators  are  more  promising.  If  the  Corps 
were  concerned  only  with  the  near  future,  then  either  SIF  or  IGES  formats 
would  be  satisfactory.  However,  a  second  generation  of  systems  that  use 
modeling  techniques  will  soon  make  much  more  information  available  if  it  can 
be  captured.  Only  ICES  has  the  technical  capability  to  capture  the  building 
and  site  "model"  and  further,  it  has  the  largest  following  in  the  industry  as 
a  whole.  Therefore,  it  is  expected  to  have  the  best  chance  of  meeting  the 
A/E/C  community's  future  needs. 

The  quality  of  translators  in  the  IGES  format  is  expected  to  improve 
greatly  as  their  use  increases  and  vendors  learn  from  experience.  In  addi¬ 
tion,  experience  in  the  aerospace  and  electronics  industries  should  resolve 
many  of  the  modeling  problems  before  the  architectural  modelers  become  avail¬ 
able.  Some  professional  organizations  are  working  on  standards  to  help  define 
the  building  model  so  it  can  also  be  translated  in  a  consistent  way. 

It  is  recommended  that  the  Corps  continue  this  work  by: 

1.  Actively  participating  on  the  IGES  A/E/C  subcommittee 

2.  Requiring  a  tested  IGES  translator  in  the  procurement  of  ail  Corps 
design  and  drafting  systems. 
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